Micron Document
<!DOCTYPE html>
<html class="client-nojs vector-feature-night-mode-disabled vector-feature-language-in-header-enabled vector-feature-language-in-main-page-header-disabled vector-feature-page-tools-pinned-disabled vector-feature-toc-pinned-clientpref-1 vector-feature-main-menu-pinned-disabled vector-feature-limited-width-clientpref-1 vector-feature-limited-width-content-enabled vector-feature-custom-font-size-clientpref-1 vector-feature-appearance-pinned-clientpref-1 vector-sticky-header-enabled" lang="en" dir="ltr"><head>
<meta charset="UTF-8">
<title>Process modeling</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="canonical" href="https://en.wikipedia.org/wiki/Process_modeling"> <link href="./mw/ext.cite.styles.css" rel="stylesheet" type="text/css">
<link href="./mw/skins.vector.icons.css" rel="stylesheet" type="text/css">
<link href="./mw/skins.vector.search.codex.styles.css" rel="stylesheet" type="text/css">
<link href="./mw/skins.vector.styles.css" rel="stylesheet" type="text/css">
<link href="./mw/user.styles.css" rel="stylesheet" type="text/css">
<meta name="ResourceLoaderDynamicStyles" content="">
<link rel="stylesheet" type="text/css" href="./mw/site.styles.css">
<link rel="stylesheet" type="text/css" href="./mw/noscript.css">
<link rel="stylesheet" type="text/css" href="./footer.css">
<link rel="stylesheet" type="text/css" href="./vector-2022.css">
</head>
<body class="skin--responsive skin-vector skin-vector-search-vue mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Process_modeling rootpage-Process_modeling skin-vector-2022 action-view">
<div class="mw-page-container">
<div class="mw-page-container-inner">
<div class="mw-content-container">
<main id="content" class="mw-body">
<header class="mw-body-header vector-page-titlebar">
<h1 id="firstHeading" class="firstHeading mw-first-heading">
<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Process modeling</span></span>
</h1>
</header>
<a id="top"></a>
<div id="bodyContent" class="vector-body ve-init-mw-desktopArticleTarget-targetContainer" aria-labelledby="firstHeading" data-mw-ve-target-container="">
<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="en" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr">
<style data-mw-deduplicate="TemplateStyles:r1236090951">
/* start https://en.wikipedia.org/ */


.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}


/* end https://en.wikipedia.org/ */
</style><div role="note" class="hatnote navigation-not-searchable">For the jargon used in the Australian republican debate, see <a href="Process_model_(Australia)" title="Process model (Australia)">Process model (Australia)</a>.</div>
<p>The term <b>process model</b> is used in various contexts. For example, in <a href="Business_process_modeling" title="Business process modeling">business process modeling</a> the enterprise process model is often referred to as the <i>business process model</i>.
</p>

<meta property="mw:PageProp/toc">
<div class="mw-heading mw-heading2"><h2 id="Overview">Overview</h2></div>
<p>Process models are <a href="https://en.wiktionary.org/wiki/Process" class="extiw external" title="wiktionary:Process">processes</a> of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.<sup id="cite_ref-Rolland1998_2-0" class="reference"><a href="#cite_note-Rolland1998-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>
</p><p>The goals of a process model are to be:
</p>
<ul><li>Descriptive
<ul><li>Track what actually happens during a process</li>
<li>Take the point of view of an external observer who looks at the way a process has been performed and determines the improvements that must be made to make it perform more effectively or efficiently.</li></ul></li>
<li>Prescriptive
<ul><li>Define the desired processes and how they should/could/might be performed.</li>
<li>Establish rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance.</li></ul></li>
<li>Explanatory
<ul><li>Provide explanations about the rationale of processes.</li>
<li>Explore and evaluate the several possible courses of action based on rational <a href="Argument" title="Argument">arguments</a>.</li>
<li>Establish an explicit link between processes and the requirements that the model needs to fulfill.</li>
<li>Pre-defines points at which data can be extracted for reporting purposes.</li></ul></li></ul>
<div class="mw-heading mw-heading2"><h2 id="Purpose">Purpose</h2></div>
<p>From a theoretical point of view, the <a href="Meta-process_modeling" title="Meta-process modeling">meta-process modeling</a> explains the key concepts needed to describe what happens in the development process, on what, when it happens, and why. From an operational point of view, the meta-process modeling is aimed at providing guidance for method engineers and application developers.<sup id="cite_ref-Rolland1993_1-1" class="reference"><a href="#cite_note-Rolland1993-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>
</p><p>The activity of <a href="Business_model" title="Business model">modeling a business</a> process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is a common driver for the need to model a business process. <a href="Change_management" title="Change management">Change management</a> programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of business process models (BPM) becoming fully executable (and capable of <a href="Round-trip_engineering" title="Round-trip engineering">round-trip engineering</a>) is coming closer to reality every day. Supporting technologies include <a href="Unified_Modeling_Language" title="Unified Modeling Language">Unified Modeling Language</a> (UML), <a href="Model-driven_architecture" title="Model-driven architecture">model-driven architecture</a>, and <a href="Service-oriented_architecture" title="Service-oriented architecture">service-oriented architecture</a>.
</p><p>Process modeling addresses the process aspects of an enterprise <a href="Business_architecture" title="Business architecture">business architecture</a>, leading to an all encompassing <a href="Enterprise_architecture" title="Enterprise architecture">enterprise architecture</a>. The relationships of a business processes in the context of the rest of the enterprise systems, data, organizational structure, strategies, etc. create greater capabilities in analyzing and planning a change. One real-world example is in corporate <a href="Mergers_and_acquisitions" title="Mergers and acquisitions">mergers and acquisitions</a>; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merger.
</p><p>Process modeling has always been a key aspect of <a href="Business_process_reengineering" class="mw-redirect" title="Business process reengineering">business process reengineering</a>, and continuous improvement approaches seen in <a href="Six_Sigma" title="Six Sigma">Six Sigma</a>.
</p>
<div class="mw-heading mw-heading2"><h2 id="Classification_of_process_models">Classification of process models</h2></div>
<div class="mw-heading mw-heading3"><h3 id="By_coverage">By coverage</h3></div>
<p>There are five types of coverage where the term process model has been defined differently:<sup id="cite_ref-Dowson1988_3-0" class="reference"><a href="#cite_note-Dowson1988-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>
</p>
<ul><li>Activity-oriented: related set of activities conducted for the specific purpose of product definition; a set of partially ordered steps intended to reach a goal.<sup id="cite_ref-Feiler1993_4-0" class="reference"><a href="#cite_note-Feiler1993-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup></li>
<li>Product-oriented: series of activities that cause sensitive product transformations to reach the desired product.<sup id="cite_ref-Sianipar2014_5-0" class="reference"><a href="#cite_note-Sianipar2014-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup></li>
<li>Decision-oriented: set of related decisions conducted for the specific purpose of product definition.</li>
<li>Context-oriented: sequence of contexts causing successive product transformations under the influence of a decision taken in a context.</li>
<li>Strategy-oriented: allow building models representing multi-approach processes and plan different possible ways to elaborate the product based on the notion of intention and strategy.<sup id="cite_ref-Rolland1999_6-0" class="reference"><a href="#cite_note-Rolland1999-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup></li></ul>
<div class="mw-heading mw-heading3"><h3 id="By_alignment">By alignment</h3></div>
<p>Processes can be of different kinds.<sup id="cite_ref-Rolland1998_2-1" class="reference"><a href="#cite_note-Rolland1998-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> These definitions "correspond to the various ways in which a process can be modelled".
</p>
<ul><li>Strategic processes
<ul><li>investigate alternative ways of doing a thing and eventually produce a plan for doing it</li>
<li>are often creative and require human co-operation; thus, alternative generation and selection from an alternative are very critical activities</li></ul></li>
<li>Tactical processes
<ul><li>help in the achievement of a plan</li>
<li>are more concerned with the tactics to be adopted for actual plan achievement than with the development of a plan of achievement</li></ul></li>
<li>Implementation processes
<ul><li>are the lowest level processes</li>
<li>are directly concerned with the details of the <i>what</i> and <i>how</i> of plan implementation</li></ul></li></ul>
<div class="mw-heading mw-heading3"><h3 id="By_granularity">By granularity</h3></div>
<p><a href="Granularity" title="Granularity">Granularity</a> refers to the level of detail of a process model and affects the kind of guidance, explanation and trace that can be provided. Coarse granularity restricts these to a rather limited level of detail whereas fine granularity provides more detailed capability. The nature of granularity needed is dependent on the situation at hand.<sup id="cite_ref-Rolland1998_2-2" class="reference"><a href="#cite_note-Rolland1998-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>
</p><p>Project manager, customer representatives, the general, top-level, or middle management require rather coarse-grained process description as they want to gain an overview of time, budget, and resource planning for their decisions. In contrast, software engineers, users, testers, analysts, or <a href="Software_system" title="Software system">software system</a> architects will prefer a fine-grained process model where the details of the model can provide them with instructions and important execution dependencies such as the dependencies between people.
</p><p>While notations for fine-grained models exist, most traditional process models are coarse-grained descriptions. Process models should, ideally, provide a wide range of granularity (e.g. Process Weaver).<sup id="cite_ref-Rolland1998_2-3" class="reference"><a href="#cite_note-Rolland1998-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Fernström1991_7-0" class="reference"><a href="#cite_note-Fernström1991-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>
</p>
<div class="mw-heading mw-heading3"><h3 id="By_flexibility">By flexibility</h3></div>

<p>It was found that while process models were prescriptive, in actual practice departures from the prescription can occur.<sup id="cite_ref-Rolland1999_6-1" class="reference"><a href="#cite_note-Rolland1999-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> Thus, frameworks for adopting methods evolved so that systems development methods match specific organizational situations and thereby improve their usefulness. The development of such frameworks is also called situational <a href="Method_engineering" title="Method engineering">method engineering</a>.
</p><p>Method construction approaches can be organized in a flexibility spectrum ranging from 'low' to 'high'.<sup id="cite_ref-HBO_8-1" class="reference"><a href="#cite_note-HBO-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>
</p><p>Lying at the 'low' end of this spectrum are rigid methods, whereas at the 'high' end there are modular method construction. Rigid methods are completely pre-defined and leave little scope for adapting them to the situation at hand. On the other hand, modular methods can be modified and augmented to fit a given situation. Selecting a rigid methods allows each project to choose its method from a panel of rigid, pre-defined methods, whereas selecting a path within a method consists of choosing the appropriate path for the situation at hand. Finally, selecting and tuning a method allows each project to select methods from different approaches and tune them to the project's needs."<sup id="cite_ref-Rolland1997_9-0" class="reference"><a href="#cite_note-Rolland1997-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>
</p>
<div class="mw-heading mw-heading2"><h2 id="Quality_of_methods">Quality of methods</h2></div>
<p>As the quality of process models is being discussed in this paper, there is a need to elaborate quality of modeling techniques as an important essence in quality of process models. In most existing frameworks created for understanding the quality, the line between quality of modeling techniques and the quality of models as a result of the application of those techniques are not clearly drawn. This report will concentrate both on quality of process modeling techniques and quality of process models to clearly differentiate the two.
Various frameworks were developed to help in understanding quality of process modeling techniques, one example is Quality based modeling evaluation framework or known as Q-Me framework which argued to provide set of well defined quality properties and procedures to make an objective assessment of this properties possible.<sup id="cite_ref-hommes_10-0" class="reference"><a href="#cite_note-hommes-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>
This framework also has advantages of providing uniform and formal description of the model element within one or different model types using one modeling techniques<sup id="cite_ref-hommes_10-1" class="reference"><a href="#cite_note-hommes-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>
In short this can make assessment of both the product quality and the process quality of modeling techniques with regard to a set of properties that have been defined before.
</p><p>Quality properties that relate to <a href="Business_process_modeling" title="Business process modeling">business process modeling</a> techniques discussed in <sup id="cite_ref-hommes_10-2" class="reference"><a href="#cite_note-hommes-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> are:
</p>
<ul><li>Expressiveness: the degree to which a given modeling technique is able to denote the models of any number and kinds of application domains.</li>
<li>Arbitrariness: the degree of freedom one has when modeling one and the same domain</li>
<li>Suitability: the degree to which a given modeling technique is specifically tailored for a specific kind of application domain.</li>
<li>Comprehensibility: the ease with which the way of working and way of modeling are understood by participants.</li>
<li>Coherence: the degree to which the individual sub models of a way of modeling constitute a whole.</li>
<li>Completeness; the degree to which all necessary concepts of the application domain are represented in the way of modeling.</li>
<li>Efficiency: the degree to which the modeling process uses resources such as time and people.</li>
<li>Effectiveness: the degree to which the modeling process achieves its goal.</li></ul>
<p>To assess the quality of Q-ME framework; it is used to illustrate the quality of the dynamic essentials modeling of the organisation (DEMO) business modeling techniques.
</p><p>It is stated that the evaluation of the Q-ME framework to the DEMO modeling techniques has revealed the shortcomings of Q-ME. One particular is that it does not include quantifiable metric to express the quality of business modeling technique which makes it hard to compare quality of different techniques in an overall rating.
</p><p>There is also a systematic approach for quality measurement of modeling techniques known as complexity metrics suggested by Rossi et al. (1996). Techniques of Meta model is used as a basis for computation of these complexity metrics. In comparison to quality framework proposed by <a href="John_Krogstie" title="John Krogstie">Krogstie</a>, quality measurement focus more on technical level instead of individual model level.<sup id="cite_ref-ReferenceA_11-0" class="reference"><a href="#cite_note-ReferenceA-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>
</p><p>Authors (Cardoso, Mendling, Neuman and Reijers, 2006) used complexity metrics to measure the simplicity and understandability of a design. This is supported by later research done by Mendling <i>et al.</i> who argued that without using the quality metrics to help question quality properties of a model, simple process can be modeled in a complex and unsuitable way. This in turn can lead to a lower understandability, higher maintenance cost and perhaps inefficient execution of the process in question.<sup id="cite_ref-MendlingMoserBPM_12-0" class="reference"><a href="#cite_note-MendlingMoserBPM-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>
</p><p>The quality of modeling technique is important in creating models that are of quality and contribute to the correctness and usefulness of models.
</p>
<div class="mw-heading mw-heading2"><h2 id="Quality_of_models">Quality of models</h2></div>
<p>Earliest process models reflected the dynamics of the process with a practical process obtained by instantiation in terms of relevant concepts, available technologies, specific implementation environments, process constraints and so on.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup>
</p><p>Enormous number of research has been done on quality of models but less focus has been shifted towards the quality of process models. Quality issues of process models cannot be evaluated exhaustively however there are four main guidelines and frameworks in practice for such. These are: top-down quality frameworks, bottom-up metrics related to quality aspects, empirical surveys related to modeling techniques, and pragmatic guidelines.<sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup>
</p><p>Hommes quoted Wang <i>et al.</i> (1994)<sup id="cite_ref-ReferenceA_11-1" class="reference"><a href="#cite_note-ReferenceA-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup> that all the main characteristic of quality of models can all be grouped under 2 groups namely correctness and usefulness of a model, correctness ranges from the model correspondence to the phenomenon that is modeled to its correspondence to syntactical rules of the modeling and also it is independent of the purpose to which the model is used.
</p><p>Whereas the usefulness can be seen as the model being helpful for the specific purpose at hand for which the model is constructed at first place. Hommes also makes a further distinction between internal correctness (empirical, syntactical and semantic quality) and external correctness (validity).
</p><p>A common starting point for defining the quality of conceptual model is to look at the linguistic properties of the modeling language of which syntax and semantics are most often applied.
</p><p>Also the broader approach is to be based on semiotics rather than linguistic as was done by Krogstie using the top-down quality framework known as SEQUAL.<sup id="cite_ref-krogstie_15-0" class="reference"><a href="#cite_note-krogstie-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup> It defines several quality aspects based on relationships between a model, knowledge Externalisation, domain, a modeling language, and the activities of learning, taking action, and modeling.
</p><p>The framework does not however provide ways to determine various degrees of quality but has been used extensively for business process modeling in empirical tests carried out <sup id="cite_ref-17" class="reference"><a href="#cite_note-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup>
According to previous research done by Moody <i>et al.</i><sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup> with use of conceptual model quality framework proposed by Lindland <i>et al.</i> (1994) to evaluate quality of process model, three levels of quality<sup id="cite_ref-19" class="reference"><a href="#cite_note-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup> were identified:
</p>
<ul><li>Syntactic quality: Assesses extent to which the model conforms to the grammar rules of modeling language being used.</li>
<li>Semantic quality: whether the model accurately represents user requirements</li>
<li>Pragmatic quality: whether the model can be understood sufficiently by all relevant stakeholders in the modeling process. That is the model should enable its interpreters to make use of it for fulfilling their need.</li></ul>
<p>From the research it was noticed that the quality framework was found to be both easy to use and useful in evaluating the quality of process models however it had limitations in regards to reliability and difficult to identify defects. These limitations led to refinement of the framework through subsequent research done by <a href="John_Krogstie" title="John Krogstie">Krogstie</a>. This framework is called SEQUEL framework by Krogstie <i>et al.</i> 1995 (Refined further by Krogstie &amp; Jørgensen, 2002) which included three more quality aspects.
</p>
<ul><li>Physical quality: whether the externalized model is persistent and available for the audience to make sense of it.</li>
<li>Empirical quality: whether the model is modeled according to the established regulations regarding a given language.</li>
<li>Social quality: This regards the agreement between the stakeholders in the modeling domain.</li></ul>
<p>Dimensions of Conceptual Quality framework<sup id="cite_ref-20" class="reference"><a href="#cite_note-20"><span class="cite-bracket">[</span>20<span class="cite-bracket">]</span></a></sup>
Modeling Domain is the set of all statements that are relevant and correct for describing a problem domain, Language Extension is the set of all statements that are possible given the grammar and vocabulary of the modeling languages used. Model Externalization is the conceptual representation of the problem domain.
</p><p>It is defined as the set of statements about the problem domain that are actually made. Social Actor Interpretation and Technical Actor Interpretation are the sets of statements that actors both human model users and the tools that interact with the model, respectively 'think' the conceptual representation of the problem domain contains.
</p><p>Finally, Participant Knowledge is the set of statements that human actors, who are involved in the modeling process, believe should be made to represent the problem domain. These quality dimensions were later divided into two groups that deal with physical and social aspects of the model.
</p><p>In later work, Krogstie et al.<sup id="cite_ref-krogstie_15-1" class="reference"><a href="#cite_note-krogstie-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup> stated that while the extension of the <a href="SEQUAL_framework" title="SEQUAL framework">SEQUAL framework</a> has fixed some of the limitation of the initial framework, however other limitation remain .
In particular, the framework is too static in its view upon semantic quality, mainly considering models, not modeling activities, and comparing these models to a static domain rather than seeing the model as a facilitator for changing the domain.
</p><p>Also, the framework's definition of pragmatic quality is quite narrow, focusing on understanding, in line with the semiotics of Morris, while newer research in linguistics and semiotics has focused beyond mere understanding, on how the model is used and affects its interpreters.
</p><p>The need for a more dynamic view in the semiotic quality framework is particularly evident when considering process models, which themselves often prescribe or even enact actions in the problem domain, hence a change to the model may also change the problem domain directly. This paper discusses the quality framework in relation to active process models and suggests a revised framework based on this.
</p><p>Further work by Krogstie <i>et al.</i> (2006) to revise SEQUAL framework to be more appropriate for active process models by redefining physical quality with a more narrow interpretation than previous research.<sup id="cite_ref-krogstie_15-2" class="reference"><a href="#cite_note-krogstie-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>
</p><p>The other framework in use is Guidelines of Modeling (GoM) <sup id="cite_ref-21" class="reference"><a href="#cite_note-21"><span class="cite-bracket">[</span>21<span class="cite-bracket">]</span></a></sup> based on general accounting principles include the six principles: Correctness, Clarity deals with the comprehensibility and explicitness (System description) of model systems.
Comprehensibility relates to graphical arrangement of the information objects and, therefore, supports the understand ability of a model.
Relevance relates to the model and the situation being presented. Comparability involves the ability to compare models that is semantic comparison between two models, Economic efficiency; the produced cost of the design process need at least to be covered by the proposed use of cost cuttings and revenue increases.
</p><p>Since the purpose of organizations in most cases is the maximization of profit, the principle defines the borderline for the modeling process. The last principle is Systematic design defines that there should be an accepted differentiation between diverse views within modeling.
Correctness, relevance and economic efficiency are prerequisites in the quality of models and must be fulfilled while the remaining guidelines are optional but necessary.
</p><p>The two frameworks SEQUAL and GOM have a limitation of use in that they cannot be used by people who are not competent with modeling. They provide major quality metrics but are not easily applicable by non-experts.
</p><p>The use of bottom-up metrics related to quality aspects of process models is trying to bridge the gap of use of the other two frameworks by non-experts in modeling but it is mostly theoretical and no empirical tests have been carried out to support their use.
</p><p>Most experiments carried out relate to the relationship between metrics and quality aspects and these works have been done individually by different authors: Canfora et al. study the connection mainly between count metrics (for example, the number of tasks or splits -and maintainability of software process models);<sup id="cite_ref-22" class="reference"><a href="#cite_note-22"><span class="cite-bracket">[</span>22<span class="cite-bracket">]</span></a></sup> Cardoso validates the correlation between control flow complexity and perceived complexity; and Mendling et al. use metrics to predict control flow errors such as deadlocks in process models.<sup id="cite_ref-MendlingMoserBPM_12-1" class="reference"><a href="#cite_note-MendlingMoserBPM-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-23" class="reference"><a href="#cite_note-23"><span class="cite-bracket">[</span>23<span class="cite-bracket">]</span></a></sup>
</p><p>The results reveal that an increase in size of a model appears to reduce its quality and comprehensibility.
Further work by Mendling et al. investigates the connection between metrics and understanding <sup id="cite_ref-mendling14_24-0" class="reference"><a href="#cite_note-mendling14-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup> and<sup id="cite_ref-25" class="reference"><a href="#cite_note-25"><span class="cite-bracket">[</span>25<span class="cite-bracket">]</span></a></sup> While some metrics are confirmed regarding their effect, also personal factors of the modeler – like competence – are revealed as important for understanding about the models.
</p><p>Several empirical surveys carried out still do not give clear guidelines or ways of evaluating the quality of process models but it is necessary to have clear set of guidelines to guide modelers in this task. Pragmatic guidelines have been proposed by different practitioners even though it is difficult to provide an exhaustive account of such guidelines from practice.
</p><p>Most of the guidelines are not easily put to practice but "label activities verb–noun" rule has been suggested by other practitioners before and analyzed empirically.
From the research.<sup id="cite_ref-26" class="reference"><a href="#cite_note-26"><span class="cite-bracket">[</span>26<span class="cite-bracket">]</span></a></sup> value of process models is not only dependent on the choice of graphical constructs but also on their annotation with textual labels which need to be analyzed. It was found that it results in better models in terms of understanding than alternative labelling styles.
</p><p>From the earlier research and ways to evaluate process model quality it has been seen that the process model's size, structure, expertise of the modeler and modularity affect its overall comprehensibility.<sup id="cite_ref-mendling14_24-1" class="reference"><a href="#cite_note-mendling14-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup>
<sup id="cite_ref-27" class="reference"><a href="#cite_note-27"><span class="cite-bracket">[</span>27<span class="cite-bracket">]</span></a></sup> Based on these a set of guidelines was presented<sup id="cite_ref-mendling19_28-0" class="reference"><a href="#cite_note-mendling19-28"><span class="cite-bracket">[</span>28<span class="cite-bracket">]</span></a></sup> 7 Process Modeling Guidelines (7PMG). This guideline uses the verb-object style, as well as guidelines on the number of elements in a model, the application of structured modeling, and the decomposition of a process model. The guidelines are as follows:
</p>
<ul><li>G1 Minimize the number of elements in a model</li>
<li>G2 Minimize the routing paths per element</li>
<li>G3 Use one start and one end event</li>
<li>G4 Model as structured as possible</li>
<li>G5 Avoid OR routing elements</li>
<li>G6 Use verb-object activity labels</li>
<li>G7 Decompose a model with more than 50 elements</li></ul>
<p>7PMG still though has limitations with its use: Validity problem 7PMG does not relate to the content of a process model, but only to the way this content is organized and represented.
It does suggest ways of organizing different structures of the process model while the content is kept intact but the pragmatic issue of what must be included in the model is still left out.
The second limitation relates to the prioritizing guideline the derived ranking has a small empirical basis as it relies on the involvement of 21 process modelers only.
</p><p>This could be seen on the one hand as a need for a wider involvement of process modelers' experience, but it also raises the question, what alternative approaches may be available to arrive at a prioritizing guideline?<sup id="cite_ref-mendling19_28-1" class="reference"><a href="#cite_note-mendling19-28"><span class="cite-bracket">[</span>28<span class="cite-bracket">]</span></a></sup>
</p>
<div class="mw-heading mw-heading2"><h2 id="See_also">See also</h2></div>
<ul><li><a href="Model_selection" title="Model selection">Model selection</a></li>
<li><a href="Process_(science)" class="mw-redirect" title="Process (science)">Process (science)</a></li>
<li><a href="Process_architecture" title="Process architecture">Process architecture</a></li>
<li><a href="Process_calculus" title="Process calculus">Process calculus</a></li>
<li><a href="Process_flow_diagram" title="Process flow diagram">Process flow diagram</a></li>
<li><a href="Process_ontology" title="Process ontology">Process ontology</a></li>
<li><a href="Process_Specification_Language" title="Process Specification Language">Process Specification Language</a></li></ul>
<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>
<style data-mw-deduplicate="TemplateStyles:r1239543626">
/* start https://en.wikipedia.org/ */


.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}


/* end https://en.wikipedia.org/ */
</style><div class="reflist reflist-columns references-column-width" style="column-width: 30em;">
<ol class="references">
<li id="cite_note-Rolland1993-1"><span class="mw-cite-backlink">^ <a href="#cite_ref-Rolland1993_1-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Rolland1993_1-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">
<a href="Colette_Rolland" title="Colette Rolland">Colette Rolland</a> (1993). <i>Modeling the Requirements Engineering Process. 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases</i>.</span>
</li>
<li id="cite_note-Rolland1998-2"><span class="mw-cite-backlink">^ <a href="#cite_ref-Rolland1998_2-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Rolland1998_2-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-Rolland1998_2-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-Rolland1998_2-3"><sup><i><b>d</b></i></sup></a></span> <span class="reference-text"><a href="Colette_Rolland" title="Colette Rolland">Colette Rolland</a> and Pernici, C. Thanos (1998). <i>A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98</i>. B. <a href="Lecture_Notes_in_Computer_Science" title="Lecture Notes in Computer Science">Lecture Notes in Computer Science</a> 1413. Springer.</span>
</li>
<li id="cite_note-Dowson1988-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-Dowson1988_3-0">^</a></b></span> <span class="reference-text">M. Dowson (1998). <i>Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering</i>.</span>
</li>
<li id="cite_note-Feiler1993-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-Feiler1993_4-0">^</a></b></span> <span class="reference-text">P.H. Feiler and <a href="W.S._Humphrey" class="mw-redirect" title="W.S. Humphrey">W.S. Humphrey</a>. (1993). <i>Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process"</i></span>
</li>
<li id="cite_note-Sianipar2014-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-Sianipar2014_5-0">^</a></b></span> <span class="reference-text">
<style data-mw-deduplicate="TemplateStyles:r1238218222">
/* start https://en.wikipedia.org/ */


.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}


/* end https://en.wikipedia.org/ */
</style><cite id="CITEREFSianiparYudokoDowakiAdhiutama2014" class="citation journal cs1">Sianipar, C.P.M.; Yudoko, G.; Dowaki, K.; Adhiutama, A. (2014). <span class="id-lock-subscription" title="Paid subscription required"><a rel="nofollow" class="external text" href="http://morganasianipar.com/publication/physiological-concept-visible-modeling-feasible-design.html">"Physiological Concept: Visible Modeling for Feasible Design"</a></span>. <i>Applied Mechanics and Materials</i>. <b>493</b>: <span class="nowrap">432–</span>437. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.4028%2Fwww.scientific.net%2FAMM.493.432">10.4028/www.scientific.net/AMM.493.432</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a>&nbsp;<a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:109776405">109776405</a>.</cite></span>
</li>
<li id="cite_note-Rolland1999-6"><span class="mw-cite-backlink">^ <a href="#cite_ref-Rolland1999_6-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Rolland1999_6-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><a href="Colette_Rolland" title="Colette Rolland">Colette Rolland</a> (1994). <i>A Multi-Model View of Process Modelling. Requirements Engineering</i>. Vol 4, Nr 4. Springer-Verlag.</span>
</li>
<li id="cite_note-Fernström1991-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-Fernström1991_7-0">^</a></b></span> <span class="reference-text">C. Fernström and L. Ohlsson (1991). <i>Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process</i>. IEEE computer Society Press.</span>
</li>
<li id="cite_note-HBO-8"><span class="mw-cite-backlink">^ <a href="#cite_ref-HBO_8-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-HBO_8-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">
A.F. Harmsen, <a href="Sjaak_Brinkkemper" title="Sjaak Brinkkemper">Sjaak Brinkkemper</a> and J.L.H. Oei (1994). <i>Situational Method Engineering for information Systems Project Approaches</i>. North Holland</span>
</li>
<li id="cite_note-Rolland1997-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-Rolland1997_9-0">^</a></b></span> <span class="reference-text"><a href="Colette_Rolland" title="Colette Rolland">Colette Rolland</a> (1997). <i>A Primer for Method Engineering. Proceedings of the INFORSID Conference</i>.</span>
</li>
<li id="cite_note-hommes-10"><span class="mw-cite-backlink">^ <a href="#cite_ref-hommes_10-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-hommes_10-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-hommes_10-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text">BJ Hommes, V Van Reijswoud, Assessing the Quality of Business Process Modeling Techniques -Proceedings of the 33rd Hawaii International Conference on System Sciences – 2000</span>
</li>
<li id="cite_note-ReferenceA-11"><span class="mw-cite-backlink">^ <a href="#cite_ref-ReferenceA_11-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-ReferenceA_11-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">Bart-Jan Hommes, <i><a rel="nofollow" class="external text" href="https://www.researchgate.net/publication/220260389_Business_Process_Change_A_Study_of_Methodologies_Techniques_and_Tools/file/72e7e52a1d6f118dba.pdf">The evaluation of business process modeling techniques</a>,</i> phd thesis TU Delft 2004</span>
</li>
<li id="cite_note-MendlingMoserBPM-12"><span class="mw-cite-backlink">^ <a href="#cite_ref-MendlingMoserBPM_12-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-MendlingMoserBPM_12-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">J. Mendling, M. Moser, G. Neumann, H. Verbeek, B. Dongen, W. van der Aalst, A Quantitative Analysis of Faulty EPCs in the SAP Reference Model, BPM Center Report BPM-06-08, BPMCenter.org, 2006.</span>
</li>
<li id="cite_note-13"><span class="mw-cite-backlink"><b><a href="#cite_ref-13">^</a></b></span> <span class="reference-text">Proceedings of the 9th international conference on Software Engineering</span>
</li>
<li id="cite_note-14"><span class="mw-cite-backlink"><b><a href="#cite_ref-14">^</a></b></span> <span class="reference-text"><cite id="CITEREFMendlingReijersvan_der_Aalst2010" class="citation journal cs1">Mendling, J.; Reijers, H. A.; van der Aalst, W. M. P. (2010). "Seven process modeling guidelines (7PMG)". <i>Information and Software Technology</i>. <b>52</b> (2): <span class="nowrap">127–</span>136. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a>&nbsp;<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.150.7953">10.1.1.150.7953</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2Fj.infsof.2009.08.004">10.1016/j.infsof.2009.08.004</a>.</cite></span>
</li>
<li id="cite_note-krogstie-15"><span class="mw-cite-backlink">^ <a href="#cite_ref-krogstie_15-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-krogstie_15-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-krogstie_15-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFKrogstieSindreJorgensen2006" class="citation journal cs1">Krogstie, J.; Sindre, G.; Jorgensen, H. (2006). "Process models representing knowledge for action: a revised quality framework". <i>European Journal of Information Systems</i>. <b>15</b> (1): <span class="nowrap">91–</span>102. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1057%2Fpalgrave.ejis.3000598">10.1057/palgrave.ejis.3000598</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a>&nbsp;<a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:16574846">16574846</a>.</cite></span>
</li>
<li id="cite_note-16"><span class="mw-cite-backlink"><b><a href="#cite_ref-16">^</a></b></span> <span class="reference-text"><cite id="CITEREFLindlandSindreSølvberg1994" class="citation journal cs1">Lindland, O.; Sindre, G.; Sølvberg, A. (1994). "Understanding quality in conceptual modeling". <i>IEEE Software</i>. <b>11</b> (2): <span class="nowrap">42–</span>49. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2F52.268955">10.1109/52.268955</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a>&nbsp;<a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:14677730">14677730</a>.</cite></span>
</li>
<li id="cite_note-17"><span class="mw-cite-backlink"><b><a href="#cite_ref-17">^</a></b></span> <span class="reference-text">D. Moody, G. Sindre, T. Brasethvik and A. Sølvberg, Evaluating the quality of process models: empirical testing of a quality framework. In: S. Spaccapietra, S.T. March and Y. Kambayashi, Editors, Conceptual Modeling – ER 2002, 21st International Conference on Conceptual Modeling, Tampere, Finland, October 7–11, 2002, Proceedings, Lecture Notes in Computer Science vol. 2503, Springer (2002), pp. 380–396.</span>
</li>
<li id="cite_note-18"><span class="mw-cite-backlink"><b><a href="#cite_ref-18">^</a></b></span> <span class="reference-text">Daniel L. Moody, G. Sindre, T. Brasethvik, A. Sølvberg. Evaluating the Quality of Process Models: Empirical Testing of a Quality Framework</span>
</li>
<li id="cite_note-19"><span class="mw-cite-backlink"><b><a href="#cite_ref-19">^</a></b></span> <span class="reference-text"><cite id="CITEREFMorris1970" class="citation book cs1">Morris, C. W. (1970). <i>Foundations of the Theory of Signs</i>. Chicago: Chicago University Press.</cite></span>
</li>
<li id="cite_note-20"><span class="mw-cite-backlink"><b><a href="#cite_ref-20">^</a></b></span> <span class="reference-text"><a href="John_Krogstie" title="John Krogstie">J. Krogstie</a>, O. Lindland, G. Sindre, Defining quality aspects for conceptual models, in: Proc. IFIP8.1 Working Conference on Information Systems Concepts: Towards a Consolidation of Views, Marburg, Germany, 1995.</span>
</li>
<li id="cite_note-21"><span class="mw-cite-backlink"><b><a href="#cite_ref-21">^</a></b></span> <span class="reference-text">J. Becker, M. Rosemann and C. Uthmann, Guidelines of business process modeling. In: W. van der Aalst, J. Desel and A. Oberweis, Editors, Business Process Management. Models, Techniques, and Empirical Studies, Springer, Berlin (2000), pp. 30–49</span>
</li>
<li id="cite_note-22"><span class="mw-cite-backlink"><b><a href="#cite_ref-22">^</a></b></span> <span class="reference-text"><cite id="CITEREFCanforaGarciaPiattiniRuiz2005" class="citation journal cs1">Canfora, G.; Garcia, F.; Piattini, M.; Ruiz, F.; Visaggio, C. (2005). "A family of experiments to validate metrics for software process models". <i>Journal of Systems and Software</i>. <b>77</b> (2): <span class="nowrap">113–</span>129. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2Fj.jss.2004.11.007">10.1016/j.jss.2004.11.007</a>.</cite></span>
</li>
<li id="cite_note-23"><span class="mw-cite-backlink"><b><a href="#cite_ref-23">^</a></b></span> <span class="reference-text">J. Mendling, Detection and prediction of errors in epc business process models, Ph.D. thesis, Vienna University of Economics and Business Administration, <a rel="nofollow" class="external free" href="http://wi.wu-wien.ac.at/home/mendling/publications/Mendling%20Doctoral%20thesis.pdf">http://wi.wu-wien.ac.at/home/mendling/publications/Mendling%20Doctoral%20thesis.pdf</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110717140629/http://wi.wu-wien.ac.at/home/mendling/publications/Mendling%20Doctoral%20thesis.pdf">Archived</a> 2011-07-17 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, 2007.</span>
</li>
<li id="cite_note-mendling14-24"><span class="mw-cite-backlink">^ <a href="#cite_ref-mendling14_24-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-mendling14_24-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">J. Mendling, H.A. Reijers and J. Cardoso, What makes process models understandable? In: G. Alonso, P. Dadam and M. Rosemann, Editors, Business Process Management, 5th International Conference, BPM 2007, Brisbane, Australia, September 24–28, 2007, Proceedings, Lecture Notes in Computer Science vol. 4714, Springer, Brisbane, Australia (2007), pp. 48–63.</span>
</li>
<li id="cite_note-25"><span class="mw-cite-backlink"><b><a href="#cite_ref-25">^</a></b></span> <span class="reference-text">J. Mendling and M. Strembeck, Influence factors of understanding business process models. In: W. Abramowicz and D. Fensel, Editors, Proceedings of the 11th International Conference on Business Information Systems (BIS 2008), Lecture Notes in Business Information Processing vol. 7, Springer-Verlag (2008), p. 142153.</span>
</li>
<li id="cite_note-26"><span class="mw-cite-backlink"><b><a href="#cite_ref-26">^</a></b></span> <span class="reference-text">J. Mendling, H.A. Reijers, J. Recker, Activity Labeling in Process Modeling: Empirical Insights and Recommendations, Information Systems. URL: &lt;<a rel="nofollow" class="external free" href="http://eprints.qut.edu.au/19625/">http://eprints.qut.edu.au/19625/</a>&gt;</span>
</li>
<li id="cite_note-27"><span class="mw-cite-backlink"><b><a href="#cite_ref-27">^</a></b></span> <span class="reference-text">H. A. Reijers, J. Mendling, Modularity in process models: Review and effects in: M. Dumas, M. Reichert, M.-C. Shan (Eds.), Business Process Management BPM 2008, Vol. 5240 of Lecture Notes in Computer Science, Springer, Milan, Italy, 2008, pp. 20-35</span>
</li>
<li id="cite_note-mendling19-28"><span class="mw-cite-backlink">^ <a href="#cite_ref-mendling19_28-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-mendling19_28-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">J. Mendling, H. A. Reijers, W. M. P. van der Aalst, Seven process modeling guidelines (7pmg), QUT ePrints Report 12340, Queensland University of Technology (2008)</span>
</li>
</ol></div>
<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>
<style data-mw-deduplicate="TemplateStyles:r1290876196">
/* start https://en.wikipedia.org/ */


.mw-parser-output .side-box{margin:4px 0;box-sizing:border-box;border:1px solid #aaa;font-size:88%;line-height:1.25em;background-color:var(--background-color-interactive-subtle,#f8f9fa);display:flow-root}.mw-parser-output .infobox .side-box{font-size:100%}.mw-parser-output .side-box-abovebelow,.mw-parser-output .side-box-text{padding:0.25em 0.9em}.mw-parser-output .side-box-image{padding:2px 0 2px 0.9em;text-align:center}.mw-parser-output .side-box-imageright{padding:2px 0.9em 2px 0;text-align:center}@media(min-width:500px){.mw-parser-output .side-box-flex{display:flex;align-items:center}.mw-parser-output .side-box-text{flex:1;min-width:0}}@media(min-width:720px){.mw-parser-output .side-box{width:238px}.mw-parser-output .side-box-right{clear:right;float:right;margin-left:1em}.mw-parser-output .side-box-left{margin-right:1em}}


/* end https://en.wikipedia.org/ */
</style><style data-mw-deduplicate="TemplateStyles:r1237033735">
/* start https://en.wikipedia.org/ */


@media print{body.ns-0 .mw-parser-output .sistersitebox{display:none!important}}@media screen{html.skin-theme-clientpref-night .mw-parser-output .sistersitebox img[src*="Wiktionary-logo-en-v2.svg"]{background-color:white}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .sistersitebox img[src*="Wiktionary-logo-en-v2.svg"]{background-color:white}}


/* end https://en.wikipedia.org/ */
</style><div class="side-box side-box-right sistersitebox"><style data-mw-deduplicate="TemplateStyles:r1126788409">
/* start https://en.wikipedia.org/ */


.mw-parser-output .plainlist ol,.mw-parser-output .plainlist ul{line-height:inherit;list-style:none;margin:0;padding:0}.mw-parser-output .plainlist ol li,.mw-parser-output .plainlist ul li{margin-bottom:0}


/* end https://en.wikipedia.org/ */
</style>
<div class="side-box-flex">
<div class="side-box-image"><span class="noviewer" typeof="mw:File"></span></div>
<div class="side-box-text plainlist">Wikimedia Commons has media related to <span style="font-weight: bold; font-style: italic;"><a href="https://commons.wikimedia.org/wiki/Category:Process_diagrams" class="extiw external" title="commons:Category:Process diagrams">Process diagrams</a></span>.</div></div>
</div>
<ul><li><a rel="nofollow" class="external text" href="ftp://ftp.informatik.uni-stuttgart.de/pub/library/medoc.ustuttgart_fi/STUD-2052/STUD-2052.pdf">Modeling processes regarding workflow patterns; link appears to be broken</a></li>
<li><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20110714110528/http://www.modelingconcepts.com/pdf/BPM_V2.pdf">"Abstraction Levels for Processes Presentation: Process Modeling Principles"</a> <span class="cs1-format">(PDF)</span>. Archived from <a rel="nofollow" class="external text" href="http://www.modelingconcepts.com/pdf/BPM_V2.pdf">the original</a> <span class="cs1-format">(PDF)</span> on 2011-07-14<span class="reference-accessdate">. Retrieved <span class="nowrap">2008-06-12</span></span>.</cite></li>
<li><a rel="nofollow" class="external text" href="http://www.apqc.org/">American Productivity and Quality Center (APQC)</a>, a worldwide organization for process and performance improvement</li>
<li><a rel="nofollow" class="external text" href="http://www.workflowpatterns.com/documentation/documents/vanderaalst98application.pdf">The Application of Petri Nets to Workflow Management</a>, W.M.P. van der Aalst, 1998.</li></ul></div><!--htdig_noindex--><div><div class="zim-footer">
This article is issued from <a class="external text" title="Last edited on 2025-05-30" href="https://en.wikipedia.org/wiki/?title=Process_modeling&amp;oldid=1292984644">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.
</div>
</div><!--/htdig_noindex--></div>
</div>
</main>
</div>
</div>
</div>

</body></html>